Events and Scripts

Scripts and Events allow you to create more complex apps by providing the ability to write your own code segments (Scripts) which can be actioned when certain things happen at runtime, such as the user clicking on a button or changing the value within a Control.

Digitise Apps includes its own Scripting language, providing a set of built-in functions (called Methods) which will provide the basis of your Scripts. The Methods cover such things as:

Form navigation,
Data access,
Property management,
Data manipulation

allowing you to quickly build up your app.

Scripts are linked to 'Events' – predefined conditions which occur within the app at runtime, for example, as mentioned earlier, when a button is clicked on by the user or when the user changes the value of a control but also by such things as when the app or a form loads or unloads. These Events are captured by the Digitise Apps Client which checks to see whether you have assigned a Script to the Event, and, if so, it runs the Script to perform the actions contained within it. Digitise Apps provides a fixed set of Events to which you can assign Scripts, but you don't have to assign a Script to all Events. Only those which are required to provide the functionality you want.

Events are only triggered by user interactions with an app, they are not triggered by programmatic interactions. For example, if you assign a Script to a Control which will be run when the contents of the Control changes, the Script will run when a user manually changes the contents of the appropriate Control, e.g. by typing in a value or making a selection, but it will not be run if you make that same change using the Scripting Methods within a Script.

App Studio includes a Script Editor allowing you to easily compose your Scripts within the development environment and assign them to the appropriate Event.

When running Scripts on Android devices, in order to improve performance, Scripts generally don't update the screen until the Script finishes executing, unless a call to a Method within the Script, such as a call to MsgBox, LoadDataSource or GetControlValue, necessitates a screen update. This means that you may not see some screen changes until the Script exits.

However, if you turn off the display of error messages, this deferred screen updating is turned off, unless you start redisplaying error messages again.